1. Field of the Invention
This invention relates to technologies for managing registered information for users of online accounts, and especially to technologies for filling and completing fields in electronic forms.
2. Background of the Invention
As the Internet has grown in popularity, and as it has become accessible to many individuals through private “home” computers, company computers, and Internet-enabled mobile devices such as Personal Communications Systems (“PCS”) wireless telephones and wireless-networked Personal Digital Assistants (“PDA”), literally thousands of service providers have deployed websites which require users to create an “account” with them. These web sites provide customized news, investment information, travel services, messaging services, genealogy mapping, classmate finding, online shopping, electronic banking, insurance claims management, and literally thousands more options, all from the convenience of the user's home, desk, or mobile device.
With so many users employing the Internet as a way to manage personal data and household financial information, consumers redundantly register numerous pieces of vital account information with various companies each day, often to gain access to these free services or subscriptions. This information often includes actual user's name, an account username, address, social security number, telephone numbers, email addresses, and even personal profile information such as gender, birth date, brand preferences, vocation, hobbies, food preferences, etc. Many sites also either assign a password to each new user, or allow the user to select a password within some constraints, such as minimum character length. Typing or entering repetitive information in this manner is not only tedious, but also drastically reduces the customer acceptance process.
As an individual's account information can be accessed via the Internet, more companies encourage their consumers to go paperless to reduce overhead costs and provide personal data at the user's convenience. From a user's perspective, the process of registering and maintaining personal login identification and password becomes cumbersome. Furthermore, since each person may have multiple accounts, tracking and managing such account information can be problematic.
Several problems arise as user's create accounts with numerous web sites and web services. First, it may become difficult to remember all of the various account usernames, especially for the sites which automatically assign an account username to each new user. For example, a user whose actual name is John A. Smith may be assigned an account username of “jasmith99X2”, or even an account username including a variation of a domain name, such as “jasmith99x2<@>hypothetical_isp<.com>”. (Due to the U.S. patent restrictions from including browser-executable code, such as actual domain names, we will use throughout this disclosure left and right bracket characters “<” and “>” to mark such text to prevent it from being executed by a web browser. But, in reading this disclosure, these bracket characters can be ignored.) In this example, a seemingly random set of characters has been added to an abbreviation of the user's actual name in order to distinguish it from the pre-existing account usernames already established with the service. So, a single user may accumulate a large number of assigned account usernames from a variety of services, such as “jasmith99x2”, “johns321a”, “jas1441qqr”, etc.
Some web sites, though, allow a user to select or pick his or her own account username, which leads to two problems. If the user's preferred account username is a common selection, the user may resort to experimenting with many variations of his or her preferred account user name until an available name is found. This often leads to the same type of variation of account username as just discussed (e.g. a string of characters related to the preferred name concatenated with some distinguishing characters).
But, if the user's preferred name is available, a second problem may arise in that the user may, and often does, select the same account username he or she has for one or more other web services. For example, if our example user John A. Smith has a fairly uncommon middle name, perhaps Arsenio, he may be able to select this as his account username on a number of unrelated web site accounts. While this is more convenient for the user in that it is easier to remember the account names, it presents a security risk to the user if the account username is ever compromised. For example, consider John Arsenio Smith creates an onlinebanking account with www<.>bigbank<.>com with an account username of “jarsenios”. It can be expected that the bank's online account system would be highly secure and hacker-safe. However, if this user also creates a personal travel planning account with www<.>cheaptrips<.>com, and selects the same account username of “jasrsenios”. This web site operator, however, may not consider their services to warrant strong protection from hackers, and may not even employ secure login procedures such as Secure Socket Layer (“SSL”), Secure Hyper Text Transfer Protocol (“HTTP S”), or Public Key Infrastructure (“PKI”) technologies. This may expose the user's favorite account username during login to snooping, which would subsequently allow another person to access the user's online bank accounts as well as any other online services having the same username.
Likewise, the same problems exist with passwords for online accounts. A large number of assigned passwords allow for greater security from account to account should one of the passwords be compromised, but may be difficult for the user to remember all of the passwords, which may result in the user writing or storing all of them in a common area (e.g. on a paper note in a desk drawer, in a note in a PDA, or in a password manager file). If the repository of collected passwords is ever compromised, the user's various accounts are vulnerable to unauthorized access. Conversely, the user-selected passwords will tend to fall into a few favorite values such as favorite color, spouse's or pet's name, college mascot, etc. Again, like the account username problem, if a common password is compromised, it may allow a hacker to access more than one account.
Therefore, there is a need in the art for a system and method for establishing or selecting account usernames which do not have common or recurring values, but which allows the user to avoid remembering or recalling a wide variety of difficult to remember (e.g. non-logical) values. Additionally, there is a need in the art for this system and method to provide adequate security from complete compromise if the central repository is compromised.
Internet users are more and more sophisticated in their understanding of hacker's techniques, and to the simple security oversights made by software manufacturers, web site operator, and service providers such as banks, utility companies, airlines, etc. Hardly a week passes where a new security flaw in a common operating system is announced, a new successful virus or worm is released, a new spyware is discovered, or a company is caught not protecting their clients' and users' personal data, including usernames and passwords.
Additionally, many users often need to allow other people access to their online accounts, even if for a limited purpose or time. For example, a manager at a company may be on a business trip, and may need to transfer some funds from an investment account to a checking account. If he or she does not have access to the Internet, he or she may call a secretary or spouse, give them the website address, their usernames and password, and ask for them to make the transfer online for them.
As a result, some user's expect that their passwords and even usernames will be comprised over time, so they routinely change their passwords and/or account usernames. Some online accounts, however, do not allow the account username to be changed, so the user's may actually close the old account and create a new one.
This process of manually managing accounts, usernames, and passwords through changes over time only accentuates the aforementioned problems.
Therefore, there is a need in the art for a system and method for establishing or selecting account passwords which do not have common or recurring values, but which allows the user to avoid remembering or recalling a wide variety of difficult to remember (e.g. non-logical) values. Additionally, there is a need in the art for this system and method to provide adequate security from complete compromise if the central repository is compromised.
One attempt at solving this information management problem that exists today is embodied in browsers such as Microsoft's™ Internet Explorer™ (“IE”), which “remembers” all the text which a user has typed previously into web forms. This data is then shown in a drop-down menue when a user enters his/her registration information, but the user must select which data to use if multiple data exists. In addition, the drop-down data may include information previously entered by other users of the same computer, which leads to a potential security lapse. Furthermore, the user still has the problem of managing multiple account login data in a potentially insecure fashion.
Other known attempts at solving this problem includes Google's™ “AutoFill” technology, and similar processes. These processes are designed to automatically complete web forms, including login screens, but actually have numerous limitations upon closer analysis. Firstly, a user's personal information is stored on each user's local computer, with their corresponding security issues and convenience limitations (e.g. the user's data input originally on one computer would not be available when the user logs in from another computer). Secondly, AutoFill requires web page authors to define field names using the Electronic Commerce Modeling Language (“ECML”) standard, and currently there are only limited fields that AutoFill can complete. As a result, most registration and log in pages today are not compatible. AutoFill is also not National Language Support (“NLS”) enabled, as it only supports English at this time.
The problem outlined has created much frustration and inconvenience, and some users have actually created data repository, such as a Lotus™ Notes™ database, to help handle this problem. However, this method has a number of drawbacks, including dependency on a computationally-intensive application (e.g. Lotus Notes), and laborious manual steps being required to input the information. Additionally, such methods lack browser integration to automatically record filled data or fill forms, ability for fast search or selective view on relevant data based on the form, as well as convenient user interfaces to enable user to perform form fill tasks quickly. FIG. 1 provides a screen shot (3) of a portion of a computer display (2) upon which a typical user's local Notes database with over 900 sets (4) of account usernames (e.g. “IDs”) (5) and passwords (6). FIG. 1 only shows entries for the letter “A” with password column (6) collapsed.
Therefore, there is a need for a system and method to address the foregoing problems and limitations of the existing art in a manner which provides more convenience to a user who has a plurality of account and web site usernames and passwords, and who repetitiously registers for new accounts and profiles online. There further exists a need in the art for this new system and method to provide ample security to avoid reusing portions of username and password strings in multiple login parameters, without causing great inconvenience to the user to remember or record a variety of greatly disparate login parameter values.